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REFERENCE TO CO-PENDING APPLICATIONS 

The subject matter of both provisional application serial number 60/056,388 filed August 
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serial number 60/255,896 filed December 18, 2000 and entitled INTELLIGENT 
TRANSPORTATION SYSTEMS WTIH AD HOC NETWORKING is also incorporated 
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BACKGROUND OF THE INVENTION 

1. FIELD OF THE INVENTION 

The present inventionrelates to automotLve telemetry prot^^^ 
5 Transportation Systems. 

2. DESCRIPTION OF THE RELATED ART 

conventionally, vehieles have been too™ to exchange data vvitB a diagnostic compute, 
10 system (such as inatepair garage) over a hard«i«d or infiared data link, or a «,^ry 
Lputer system (such as an electronic toll highway) by a data linic using a low pow 



More sophisticated vehicular teleme«y for commercial fleets has been made poss*le m 
tas, several years through both terrestrial and satellite RF packet networks. In the^. 
vehicular telemetry systems, vehicle sensor data can be transpdr^ over wrreless data 
^ ^ a computer that is programmed to monitor ^d record automotive ph^omena and 
,„ support database syst^ferveMcuh. maintenance. witiroutti,e need for ti^evehrd^ 

be in a particular service bay for example. However, these systems are relatively 

expensive to operate. 

A considerable ^ount of research is being dedicated to developing f^ble mteUigent 
vehicle Hi^«ay Systems aVHS) which are computer-assisted methods to manage 
highway infiastructures. synchronize tiafflc lights, measure traffic flow, ti, alert drrv^ to 
ongoing traffrc conditions through electiomc billboards and oflter im>ovat.ons am^ed at 
improving the quaUty and efficiency of road ttansportation systems lor vehicles. 

^ California Air Resources Board (CARB) has been a leader in establishing s^ 
for monitormg vehicle emissions. A recent CARB initiative, known as OBD-in, rs th. 
, fljrd generation of or^board diagnostic re,uiren,=nts. caUing for a. emissions regul^ry 
agency to retrieve, remotely, diagnostic data torn vehicles, tirereby avoiding the need for 
avisi. toacleanair inspection statiot^InonepUotpro^slow-powertranspond^ was 

^ on each vehicle, capable of transferring data betwe»r ti« vehicle and a roadstde 
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^iv«. Ofoour,e.taorderibrtoOBD-nipropo=altoproce«l.eachvehic,em,^mve 
...Stem capable of c»necdng™idi,pa«bi»«««^ues.eada.ateo.gh^^^ 
CARB is actively revie«tag cunentty available fetologies and is surveymg tiie 
.eleco— aiions tadusfy to see what fWure equipment is plam>ed. Tie o^^B , 
5 platfo^s tested .bus far by CARB have be» relatively cumbersome and have l.m«ed 
Lpability to be used for other data excbange needs in *e f«ure. There . 
finding a platform that ™iU be economical operate in order to mmmuze the financud 
burdenplacedontheconsumertoimplementtheproposal. 

10 Mother, it would be desirable for the chosen platform to be capable of doing more than 
iust sending diagnostic iuformation to a clean air agency. Both the telecom and a^ 
industries are looMng at ways to utilize the ..mendous business opportumtres of r^g 
^ commuters itr their vehicles whUe the, devote several hours each day to the,r 
commute. 

" vehicular traffic has become a maj» problem for urban planners. Witi, land values 
skyrocketing and land-use issues becoming more of a concern. plam>ers are lookmg for 
ways of getting more vehicles ti^ugb existing commuter arteries - - — 
exuding them. It is also known fl-t the acti^ volume of traffic h^dl«l by a 

,0 lugh^^P— whentrafflcbecomescong.s.ed.Tbere*,re.itwouldbe^^^^ 
tohavethicleswhicharecapableofexchangingda«.wi.hti.emselvesasawaytoc„n^i 
such tiungs as safe driving dis^mces to avoid collisions and exchanging data wrtir traffic 
monitoring systems to control such things as driving speeds. 

25 It is ti-erefbre an object of fte ptesent invention to provide an imp^ved platform for 
vehicular telemetry. 

It isafinther Object of th^pres^^ invention to provide an imp^vedvchic^.^^^ 

s,^ which is relatively inexpensive, ye. capable of exchangmg a range of useful dau. 
30 tiuoughadatacommunicadonssystembeti^eenavehicleandaflxedlocatron. 

It is still a lusher object of ^ present invention to provide a vehicle communications 
l;irLwMch tire lc.es ti^rein are e»:hca,»ble of communicating boti^ 
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data communications system and with themselves. 

SUMMARY OF THE INVENTION 

5 In one of its aspects, the present invention provides a method of conveying vehicle 
operation data from a vehicle to a remote monitoring recipient, comprising the steps of: 

- establishhxg a data link between the vehicle and the remote monitoring 
recipient; 

10 

- collecting vehicle operation data from data sources in the vehicle; 

- packaging the vehicle operation data in a data packet using protocol derived 
from SNMP; and 

15 ■ 

- conveying the data packet over the data link. 

In another of its aspects, the present invention provides a method of conveying vehicle 
operation data from a vehicle server to a remote monitoring cUent, comprising the steps of: 



20 



- establishing a data link between the vehicle and the remote monitoring cUent; 

- collecting vehicle operation data from data sources in Ihe vehicle server; 

- packaging the data in a protocol data unit having a protocol data unit payload, 
the payload including a plurality of VARIABLE BINDING fields, each 
VARIABLE BINDING field having an OBJECT IDENTIFIER field of two 
bytes, a VALUE TYPE field of one byte and a VARIABLE BINDING value 
of a size according to the VALUE TYPE field ; and 

- conveying the protocol data unit over the data Imk. 

In still another of its aspects, the present invention provides a method of coUecting vehicle 
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cperaaon daU from a vehide for later ttansnussion to a r^ote mooitoring recipient ia^a 
l^.„™.^.heba.dWid«..«,uirenten tsfbrthelatertra— on,com^^^^ 

steps of: 

- providing a vdiicleon-boaidcoinputing device; 

. providing a number of data acqmsiUon modules, each to measure one or more 
operating characteristics of the vehicle, the operating characterist.cs 
corresponding to current values of a s« of managed otjects; 

. . interftcmg the vehicle on-boaxd computing device wiflr each of fl.e dam 
acquisition modules; 
. configuringthevehicleon-hoanlconsn'ttagdeviceto: 

' a) form a diagnostic information base for receiving and storing values for 

eaA of the managed objects ftom each of the corresponding data 
acqmsition modules; 

0 b) assemble an event rqx^t baaed on information contained in the 

diagaostic information base; and 

0 package the even, report in a protocol data umt acco«iing to. an SNMP- 

derived protocol. 

Preferably. «.e operating charact«istics include such things as GPS position. «.^e 

^c emis^ns. Or« OBD-H par.«neter is misfire detection. «,ough o^ers ^ also 
applicable, such as Ihe O2 sensor. 

^ one embodiment. present invention ftrther comprises fl. atep of enabUng the 

vehicle on-board computing device to: 



25 
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a) estabUsh a data link with the remote monitoring recipient; a 

b) convey the protocol data unit over the data link. 



5 Ji. collecdng packaging ^ -veying ^ may oc»r a. the san,e or *ey 

occur a. diiteren. time.. The device, in ^ case, may be c^led to coU^ 

daa at regular or irregular intervals and accumulate some Wes of data for later 
^ansmissiou, such as distancetraveUed. or ofl^er types of data for immediate trans™ 

such as a current GPS position or an exceeded regulatory teeshold. Altemattvely, the^ 
,0 may be some instances where the compudng device is enabled to convey .he protocol data 

unit over a wired or other data link. 

Preferably, fl» method includes the step of enabling the remote moni«>ringr«ipien..» 
i^ue a GET protocol data unit to retrieve the current values tor a specific set of managed 
:5 ohjectsftomtbevehicleon-boardcomputingdevice. In *is case, the r«note mom^ 
reipient is eu^led to v«t for an acknowledgement to *e GET protocol dataumtby the 

vehicle on-board computing device. 

Preferably, the method h^ludes step of enabling the vehicle on-board computing 
20 devicetoissueaTRAPp«.tocoldataunittoTeportaveblculareveM. 

Preferably, the method includes the step of enabling the vehicle on-board computing 

device to: 

25 a) storethresholdvaluesorareportingintervaltoreachvehioulareventia™! 

b) issue each TRAP protocol data unit, cither when a threshold value has been 
exceeded or at a corresponding reporting interval. 
30 intbiscas^theTOAPprotocoldataunitmayreportsuchvehiolereportsasGPSposition 
and the like. 

Prrferably: the method h»b«ies the step of issuing «t MOim protocol data unit to^ 
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the vehicle to report an exceptior^ vehicular event. The method, in this case, preferably 
includes the step of enabling the vehicle on-board computmg device to: 

a) storeanyoheofapluralityofspecificationsforexceptionalvehiculareventsin 
5 the diagnostic information base, mcluding one or more regulatory exceptions, 

maintenance exceptions or operational exceptions; and 

b) issue the INFORM protocol data unit v.hen any one of the specified events 
occurs. 

to on. mbodimenl. fhe diagnosUo information base contains a specification of what 
constimtestl^occuxrenceofan-evenfandnotfteeventitself. When event oconrs, a 
«cord of the event is made in a mission queue and remains tl«re unt.1 an 
acknowledgement message (in Ms case a RESP message) is received by tire onboa«l 
,5 comnuangdevic. Accordingly, the method provides, in one embodiment, for a storage of 

vehicular events in a register or ofter temper storage module, the events bemg 

specified in the diagnostic inftmnation base. 

The managed object, for example, may be ENGINE TOMPERATURft and the conditions 
20 for*atmanagedobjec.maybeaMAXIMUMTHBESHOUD.C™TVALXlE.anda 
TIME COUNT for recording vAen the current value is to be measured. 

An example of a diagnostic information base is shown m the foUowing table: 



MANAGED 




1 VALUE 2 


VALUES 


VALUE 4 


OBJECT 


1 VALUE 1 
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TE: ENGINE 


THRESHOLD 


CURRENT 


1 'rcA/TDTJ'R ATT TRF 




VALUE 


T02: 02 


THRESHOLD 


CURRENT 


SENSOR 




VALUE 



j MEASURE- 

EVERY 
lOMINUTES 



MEASURE 

EVERY 30 
MINUTES 



An example of an event recording register is shown in the following table showing the 
current values for the managed objects at a particular time T - Tl 



TABLE 2 



Xti 
Yti 



In one example, the INFORM protocol data unit is sent as a result of a regulatory 
threshold level being exceeded. 

Preferably fte method includes the step of enablmg the vehieolar onboard computing 
device to wait for a confirmation that a pevious INFOBM protocol data unit has been 
logged in a data base by .he remote monitoring recipient In .his case, fte method 
preferably also includes to step of re-transmitting the INFORM protocol data unit in ttu> 
abse,rceofaconfirmaaontha.apreviousINFORMpn>.o«>lda.aunit has been loggedma 

database by the remote monitoring recipient. 

Preferably the method includes the step of enabling the remote monitoring recipient to 
issueaSET protocol dataunittothevehicleon-board computing devicetoset one or more 

of the managed objects. 



SUBSTITUTE SHEET (RULE 26) 



Thev™el«sd^Urkmaybearadiofte,>>encyband»deriheIEEE802.11 s^mdard, a 
satemte RF padtrt Mtwoik or a tenesttial RF packet newo* 

5 i„o„eenJ»di«»ni.tepr<«c.lda.a™itisa»r«r^ 

p;o»col data umt. the pro«KOl data unit exdudtog the ERROR STATUS and ERROR 
INDEX fields of the SNMP protocol. 

la one embodimem. the pro«>col data nnit eKcl«des .be I^GTH field of each variable 
10 binding of the SNMP pirotocol. 

Insmianotherofitsasp,cts,thepresentinventionprovidesam^^^^ 

operation data from a vehicle to aremote monitoring recipient, comprising the steps of: 

15 - establishing a data link between the vehicle and the remote monitoring 

recipient; 

- collectingvehicleoperationdatafromdatasourcesinthevehicle; 

20 - packaging the vehicle operation data in a data packet using protocol derived 

from SNMP; and 

- conveying the data packet over the data link, the protocol data unit being issued 
in response toarequest by the remote morutoring recipient and containing both 

25 the request and requested values in the request and being encapsulated within a 

single message and in a single unfragmented network packet. 

In stiU another of its aspects, the present mventionprovidesamethod of collecting veMd^ 
operation data from a vehicle for later transmission to a remote monitoring reapxent m a 
30 rnannertominimizelhebandwidthrequirementsforthelatertransmis^^^^ 

steps of: 

- providing a vehicle on-board computmg device; 



SUBSTITUTE SHEET (RULE 26) 



. providing a number of data acquisition modules, each to record a current value 
of a managed object of the vehicle; 

- interfacing the vehicle on-board computing device with each of the data 
acquisition modules; 

- configuring the vehicle on-board computing device to: 

a) form a diagnostic infomiation base for receiving and storing values of 
the managed objects from each of the data acquisition modules; 

b) assemble an event report based on information contained in the 
diagnostic information base; and 

c) package the event report into a protocol data unit, the protocol data unit 
including a protocol data unit payload having a plurality of VARIABLE 
BINDING fields, each VARIABLE BINDING field having an OBJECT 
IDENTIFIER field of two bytes, a VALUE TYPE field of one byte and a 
VARIABLE BINDING value of a size according to the VALUE TYPE 
field. 

In one embodiment, the protocol data unit includes a header.having a PDU TYPE data 
element with a value corresponding to one of a set of values, the set including a GET 
value,aSETvalue,aTRAP value, an INFORM value andaRESPONSE value. 

In still another of its aspects, the present invention provides a computer implemented 
system for conveying vehicle operation data from a vehide to a remote inonitonng 
recipient, comprising: 

. a vehicle on-board computing device in communication with a number of 
vehicle operation data sources in the vehicle; 
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. a wireless communications device for estabUshing a weless data link with the 
vehicle ou-board computing device and the remote monitoring recipient; 

. . the vehicle on-board computing device being enabled to package the vehicle 
operation data in a data packet using protocol derived from SNMP for 
, transmissiontotheremotemonitoringrecipientoverthewirelessdatalmk. 

In stUl another of its aspects, the present invention provides a computer-readable data 
^cture for collecting arxd conveying vehicle operation data from a vehicle to a 
remote monitoring recipient, comprising: 

. an appUcation module for receiving vehicle operation data from a number of 
data sources in the vehicle; 

. a storage module for storing a diagnostic mformation base, the diagnostic 
irformatioix base including a number of managed objects for a number of 
vehicle operation parameters and a number of values for each of the managed 
objects; and 

. a conmunication module for conveying protocol data units under a protocol 
■ derived torn SNMP over a v«ieless data link to the remote monitormg 

recipient. 

L, *11 another of its aspects, the preset invention provides a computer program product 
^^coded in a computer readable medium including a pluraUty of computer executable 
«eps for a computer on-bo.«xi a vehicle for coUecting and conveying vehicle operaUon 
data ftom lie vehicle to a remote monitoring lecipient, comprising: 

- receivingvehideoperationdatafromanumberofdatasomcesinthevehicle; 

- ^g. in a diagnostic infbrmaaon base, a plurality of managed objects for 
each of anumber of v*icle operation parameters; 
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. establishing a wireless data link between Ihe computer and the remote 
monitoring recipient. 

- conveying a n«mb« of protocol daM units under a protocol derived torn 
SNMP over a wireless data link to tbe remote monitoring recipient 

to still another of its aspects, fte present invention provides a ^gM propagated on a 
carrier medium, the signal including a packaged protocol data unit containing a payload 
encoding predetermined operational data of an automotive vehicle, according toaprotocol 

derived from SNMP. 

Preferably, the payload includes a plurality of VARIABIB BINDING fields each 
VAWABLE BINDINO field having an OBJECT IDENTIFm field of t«o bytes, a 
VALUE TYPE field of one byte and a VAMABLE BINDING value of a size accprdmg to 
the VALUE TYPE field data unit. 

Preferably, the payload includes a GPS position segment, a OPS heading segment, a 
vehicle speed segment or an OBOn vehicle emissions segment 

in stm another of its aspects, the present invention provides a system for conveying 
vehicle operation data ftom a vehicle to a remote monitoring recipient, comprrsmg: 

. vehicleon-boardcomputingmeansmcommunicattohvrtthammiherofvehicle 
operation data source means in tiie vehicle; 

. wtelcss communications means for establishing a vnreless data link with fte 
vehicle on-board computing means and the remote monitoring recipient; 

. ftc vehicle on-board computing means being enabled to package the vehicle 
, . operation data in a data packet using protocol derived fiom SNMP for 
ttansmission to the remote monitoring recipient over the vtoless datalmk. 

I„stiUano.herofi.saspects,thepresen.inventionp™vides.methodofconveyingvehiole 
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operation data ftom a vehicle to aremote monitoring recipient, comprising: 

. a step for estabUshing a data liiJ. between the vehicle and the remote 

monitoring recipient; 
. astepforcoU<«ttngveUcle<.p«ati<mdataflxmdataso»roesmtheveU^^^^ 

. a step for packaging *e vehicle operation toa to a data packet »^ protocol 
derived fium SNMP; and 

- astepforconveyingthedatapacketoverlhedatalink. 

In yet another of its aspects, there is provided a eon>puter-readable data for 
coUecting and conveying vehicle operation dam ftom a vehicle to a remote momtomrg 

recipient, comprising: 

. an appUcation module for receiving vehicle operation data from a number of 

data sources in the vehicle; 
- a storage module for storing a diagnostic information base, the diagnostic 

information base including a number of managed objects for a number of 

vehicle operation parameters and a number of values for each of the managed 

objects; and 

. a conmrunication module for conveying protocol data units nnder a protocol 
derived fiom SNMP over a wireless data link to the remote monitonng 
recipient. 

in stiU anote of its aspecU. the present invention provides a communications network for 
, exchanging data between a plurality of vehicles, comprising a computing unit onboaM a 
cor^sponding vehicle, wherein the computing unit in a given vehicle is operable to 
broadcast identity messages and to receive equivalent identity messages ftom other 
vehicles in an adjacent region, where said messages are used to identify the neighbotmng 
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vehicles in 



toi««o&teexch^ data™* sel^ted ones of the vAideslhereto. 



P«S^ly,*e«>mputmgunHtaoperableto»pdatealistof,.eightaurmgveUcles.Inans 
ca^ 4e con^g unit n>ay add t^w neighbour vehicles «. the list as identity messages 
axe received fiom new vehicles entering region. Aitematively, .he conaputing unit may 
delete a given neighbour vehicle ftom list ,vhen identity messages are not recerved 
ftom the given neighbour vehicle after a predetermined period ottime. Altematrvely the 
computing unit deletes a ^ven neighbour vehicle vehicles fi»m fte neighbour da^base 
vAentolack of identity messages receivedftom the given neighbour vehicle mdtcate that 

the neighbour vehicle has left the ai^aoent regioa 

P^ly, the medimn of communications is a high foquency cham.eU^ RF band and 
its use by each of said computing units is controlled according to the IEEE 802.11 
Medium Access Control (MAC) protocol. 

Preferably, the computing units are Internet addressable. 
Preferably, the oompnling units are IPv6 addressable. 
, P.eferabIy,thecomputingunitsexchangedatausinganSNMP-derivedprotocol. 

Desirably, the identity messages include OPS mfbrma«on and the IEEE 802.11 MAC 
address of the sender, wherem GPS information inctades latitude, longitude, speed and 

heading information. 

' to one embodiment. aU vehicles in the neighborhood broadcast fteir identity messages 
over a discovery time period that is sufficient to allow any given vehicle to recogmze dl 
its neighbours. Both the length of the discovery period and the geographic size of the 
region may be adjusted in proportion «, the average speed of 4e vehicles m dre 

30 neighborhood. 

If desired, the channel selection for transmission of a. least some messages may be based 
on GPS heading. 
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to one embodimeoi cad. of the computing umts fcAer comprises a transmitter and 
recdvercapableofttansnrittrngandiecdvingmessagesunderanSNMPpiotocol. 

. to^o,herofitsaspecU.fl-pres«ntinventionprovidesan»«omotivov=hicleasabove. 

,*sdUanotheroftoaspects.thep.esentinven,ionpn.VKlesad..as.m^ 

speed segme„t,aheadi„g segment and position segment. Prefcrably.thepos.Uon segment 

includes a longitude portion and a latitude portion. 

to another of its aspects, the present inver^on provides a signal propagated on a c«ri« 
medium, the signal ■ncludingaspeedsegment.aheadingsepnenta^iaposition segment 

Preferably.thepositionsegmentincludesalongitudeportionandalatitudeporuon. 

15 In stiU another of its aspects, the preset invention provides a vehicle comprising an 
onboard computing unit operable to receive messages ftom otor vehicles in an ad.acen. 
region for assembling a neighbourhood Ust fcr exchanging data vrtth selected ones of the 
vehicles listed therein. 

20 u.yetauoti.erofi.saspects.ti»presen.inventionprovidescomp»terprogrampro*.ctfor 

opLting a pro^ammable computer system on board a motor vehicle. compr.smg a 
computer readable medium mcluding the computer executable steps of recervm^ 
from oti.er vehicles in an adjacent region and of assembling a nc^ourhood Its. for 
excban^ data «th selected ones of the vehicles listed therein. 
^ My..ano,herofitsaspec.s.thepres^tmventionprovidesamotorvehiolecomprisingan 
ori«ri geneml purpose computer and a spectrum radio, the spread spectrum radto 

operable to estabUsh a data link «ifl. a radio in at least one other neighbounng vehtcle. 
,^inthecomput^is<^».etorecordmessagesfromatleas.oneott.ervch.cleman 

30 adjacent region for assemblhrg . neighbourhood Us., and to identify at least one vehtcular > 
event from data received on the data link. 

In ye. anoti»r of its objects, the pres«.. invention i»»vides a compute.re»iable da«. 
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structure for coUecting and conveying vehicle operation data from a vehicle on-board 
computing device ^d a remote monitoring recipient, comprising: 

- a module for indexing a series of protocol values and corresponding requests 
5 . and responses for data exchange between the vehicle on-board computing 

device and the remote monitoring recipient; 

- amoduleforindexingaseriesofmanagedobjects.for a number ofoperatmg 
characteristics of the vehicle; and 

- a module for recording values for each of the managed objects. 

10 Preferably, the data structure further comprises a module for indexing an identity for each 
remote monitoring recipient. 

Preferably, the data structure also includes a module for indexing a list of one or more 
authorization levels for each remote monitoring recipient. TTxese authorization levels may 
be used to impose conditions on the managed object values bemg conveyed to the 
15 recipient. Some recipients may be entitied to all of tixe managed object values, otixers to 
only some of the them, and still other requesting entities (tiiose not in ti.e list) entitied to 
none at aU. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Several preferred embodiments of tiie present invention will be provided, by way 
of example only; with reference to the appended drawing, wherein: 

Figure 1 is a schematic view of a protocol stack; 

Figure 2 is a schematic view of a UDP based protocol; 

Figure 3 is a schematic view of a TCP based protocol; 

Figure 4 is a schematic view of aheader in aUDP based protocol; 
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Figures 5(a) and (b) are perspective schematic views of two network arrangements; 

Figure 6 is a schematic view of an SNMP protocol datannit; 
5 FigureTisaschematicsequentialviewofadatagramexchange; 

Figure 8 is a schematic view of a GET protocol dataunit example; 

Figure 9 is a schematic view of an MIB hierarchy for SNMP; 
10 Figure 10 is a schematic view of a portion of a DIB hierarchy; 

Figure 11 is a schematic view of amessage sequence; 

Figure 1 2 is a schematic view of a network; 
" Figure ,3 isaschemticvLewof aprotocols«>ckfor«ohangingd=tausingftena«,oA<>f 

figure 12; 

Figure 14 is a schematic view of another network; 

20 

Figure 15 is a time plot of beacon frame sequence; 
Figure 16a is a schematic view of a portion of an adhoc network; 
25 Figure 16bisatimeplotofbeaconframesissuedbyvehiclesinnetworkoffigurel6a; 

Figure 17 is a schematic view of another adhoc network 
Figure 18 is a schematic view of another protocol stack;. 
Figure 1 9 is a schematic view of another protocol data unit; 

17 
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Figure 20 is a sohemaflc view of a quadrant divided highway segment; 
FigureMisaschematie view ofadata exchange duringadrivingmanoeuvie; and 

Figure 22 isaschematioviewof dam exchange during anott«rdnvingmanoeuv«. 

DESCRimON OF THE PREEERKBD EMBODIMENTS 

Described herein below is a system and method which implements a peer-to-peer In««net- 
based^protocol stack for vehicular diagnostic telemetry. This stack is tatended to res.de m 
on-hoard vehicul^ embedded systems and to enable remote PC workstadons to interact 
with these systems using standard commumcadons API's such as Wmsock. 
The Session and Presentation layers of the stack are labeled the Automotive Telemetry 
Protocol (ATP). ATP addresses the need for a clear specification of the message formats, 
protocol procedures, security mechanisms and external bi.er&ces by which software can 
be developed for hnplementation of OBD-ffl- on difierent mobile and fixed computrng 
platforms in an inter-operable fashion. 

Reviewed below are the objecdves sought and then provides a mot. de«uled description of 
the layers 3-6 (network, transport, session and presentation). It has been showr. that tire 
session and Presentation layers are derived trom the specifications for S-Ple Net-* 
Management Protocol (SNMP). The underlying transport mechamsm is a UDP/IP stack 
wid, die UDP header compressed m die interest of bandwiddi efficiency. 

The issue of security is also addressed below, and the ability to configure an 
25 implemen.ationofdicstacksuchdiatspecificsou.cesofdataca„beres.ric^tospec.fic 

guesting entities ("clients"). The appUcatio. of die Secure Sock« L.yer.(SSL) protocol 
is reviewed m order to demonstrate die authentication of requests for information fiom 
external sources by the on-board computer. 

^^^^^^^^^^^^^^^^^^^^ 
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The p»«K0l suck is appUed ,0 exchange o. operational daU between veWcles on me 
^ ms is based on concept of an "ad-hoc network" established wrthm a 
■neighboAood" snxrounding any give, vehicle. The ad-hoc network can co-exist wrth a 
aau link «, to tatemet, ^ing Are same BF n^»m, pro^Hded that a roadsrde 
taftastmc^^e is deployed. Th« potential of this technology «> improve highw safety ts 
iUusnated with various examples of vehicle-tcvehicle exchange of operational 
information. 

Also described a method for the integration of IEEE 802.11 compliant technology in both 
intelUg«rt vehicle and inteUigenthighway systems. R«fer«.cewUl be made hereinbelow 

to toteUigent Transportation Systems or ITS .0 encompass any component of such 
systems, whether on board a vefdcle or part of ttie roadway inftastrucn™. 

Much of the cur^ni focm of inteUigent vehicle technology is directed a. coUision 
avoidance based on radar. On the o.h.rhand,in.eUigenthighwaysys.e«development has 

been largely predicated on use of short-range communicadons between .he vehtcle and 
^ madway inftasm-cture. However exp^s ftom both the automotive OEMs as wen as 
ftom government agencies have recognized tirat vehicle-to-vehicle ' commumcations 
constitutes an area that should be explored going forward. 

The IEEE 802.1 1 specification is a relatively new standard for high-speed wireless Local 
Are. Networks (LAN). K uses a method of RF tiansmission known as sprea, specn^ 
fer which the 2.4 GHz range has been made available as an unlicensed band. Tins 
technology is also identified under to comme^ial bamrer Wi-Fi (Wireless F dehty). Its 
potential for application in to area of ITS is based on its comme«ial potential. There are 
now Wi-Fi products ommrerciaUy available d.at make it possible .0 crea^ n^ork 
inftastructures supporting mobiUty for compu« devices. Network interfi^caM^ 
arc available enabling personal computers, mcludmg laptops and notebooks. *.useW-Fr. 
AstopopularityofWi-Figrows.itisexp«.cdthatmoremobilewirelessapplumces(e.g^ 
PDA's, cell phonesiwihappe^intomarketplacethatexploitagrowinginft^sti^ 
30 ac^ poir.,s teou^ which users can connect to h^emet wirelessly a, brt Wer 
rates that currently reach 1 1 Mbps. 
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one of IEEE S02.U is ^ ««ion of a. *<,c networBng, which en,hies ^vo o 

LaevicesU,~ca.ai«cUy^«.oneanoth«wi*ou..e^afl«daco. 

,„i„t in other word^ .h. net^o* — o*- is no. a n™ con<h.on fo 
L^ecttvity be«.«n mobil. devices. A. a «sul, .EEE 802.11 can suppo« concu^n. 

; lelc-loLcleandveMcle-^-infias.™^ 

«ays TMsoon.bin.aoa of «.fiom a technical p^spcc^ve, and comn«rc.a. 

appeal, is .he essential rationale for «smg EEE 802.11 talTS. 

The method described in this document adheres to 4e principle of hnplenrenting My- 
0 compliant 802.11 nodes, without modifica«on of the speciflcat.on. to meet fl» 
requirements of ad hoc networking for ITS. 

Relationship to ATP 

.5 Tte nreftods described here are tatended «, p-vide a platfom. on which the A— 
WemetryPtotocoUAlDcaa operate between two vehicles. ATP .s a sessron evd 
plLTderived ^m Sl«^ enables a bi^on. cUent-^r^^^^ 
: L.abUshedbenveen.he«voendpoin.sofa«nK*Ueconnnnrnca«,nsm. Infl.econte^ 
of vehicle-to-veMcle oonnnunications. AIT aUov. a "cUent" veh.cle to send^ 

,0 lchronons.K.tificaaontospecified.W^veMelere^ackr,owledgementT^ 
«pes..respon^mechanismhasappUcatio„sdescnWWerinthisdoc™ren.. 

PROTOCOL STACK 

Figure 1 iUustrates the complete protocol stadcth^ is re^r^ed for OBDULusingthe OS. 
25 (Open Systems Interconnect) reference model. 

The protocol stack is intended*, meet one or more ofthefoUowingoliectives: 

• Wireless data link transparency 

This refers to the need for technology-independence. It should be posrible tor OBD-IU 
r:p:Ltobeme.usingavarie.yofwire.essdataan..eohnc.ogies. MobUedevrces 



SUBSTITUTE SHEET (RULE 26) 



10 



or any combination thereof. 

. Internet connectivity (besani OEM portals) 

„ shouid be possible for wor.^... « ren,o.e IP addresses to - 
on-board veMcniar device *a. interf^ ^ OBD and cUrer 0,^0^ -thnt 
vebide, in otber words, ^ii Internet conneCvity between the vebrcle and s^r^o^ 
.ost isadesired outcome that wm enable authorized hosts to run apphcatt^ d»t^ 
^vetotransit«.OEM.spor«s.ms implies *at*e vehicular devrce needs to^y 

with sunrdard protocol specitications that support peer-to-peer exchan^s wrft any 
rlrized host on the hrten^t. (See Security below in relaUon to ^ notron of 
cMthorizedhost). ■ 
• Efficient bandwidth utilization 

The data exchange between fixed sites, responsible for nK-nitoring. and the mobile uni« 
rrno beule...ari.y.Verb„.^ Tltereisatendcncyhtwirelessapphca^c^.^^ 
,5 ^le.hatson.eforn>of»Web"prescnta.onisre^U.simpU^«»us.m«rft^ 
;^r«Mch has been partly responsible for the developtnent of W^ic^^^ 

(WAP). WAP is a technique that offers sonte cbmprom.. b^^ ^ J 
features of *e web and the need for bandwidth effrciency over atrhnks. Noneofttte^ 

::dLtions take ^ account the fact that telemetry traffic is ,ui« d.^.^ - 
20 purpose than o*er fo^s of wireless data and should be supported m a dtfl^ ye. 
Standards-based maimer. 
• Standardized data exchange mechanism 

T^ehi^er levels (SessionandPresen.ati.n)ofthepro.oco.stac.need.^^^^ 
for obvious reasons. TOs will simpli^ .ask of comphance wtth OBD-HI m aU 
25 jurisdictionsthalchoosetohnplementtberegulations. 

• Security 

Tie need for security has been stressed by CARE. Political acceptance of the OBMI 
^.l^. on the publics confrdence that .e technology will tto. become a 
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fonn of sMe tattusion into mdividual, privacy. Motoric and vehicle owners should have 
fte perception U»t eleettonic oor^rols over the release of mfonnation are a. leas, as 
eflective as those ftat are currently in use in Web-based E-commerce. I. is contenaplated 
that the present system wiU, if needed, he capable of implementing pubhc key 
cryp«>^hy above the Session layer, in much ti« same manner ftat 1. is done m 
, business-to-consumer E-commerce. Ms ensures that, alti^ugh there is connectn,rty «tir 
any host on to Internet, only those hosts ftat obtain authorization through the security 
mechanisms wiU receive any "attention" ftom the vehicle. 

.^.^T^IIDP/lP-ln order to understandtocontext in whichATT 
operates, the underlying tr^port mechanism «hich supports ifs needs to be considered, 
ne user Datagram Protocol. (UDP) is a transport-level mechanism &r "connectionless 
client-server communications. UDP constttirtes one of the transport pmtocols that can 
operate over .he Internet. TTe notion of a "connectionless" protocol refers to the feet tiiat 
fl^ere is no overhead dedicated to to maintenance of reliable end-to-end commumcatrons. 
; to flus sense. UDP is distinguished from TCP (Transport Control Proti>col). Ti. shorter • 
UDP header (8 bytes) reflects tins difference. 

The basic protocol datii unit (PDU) of to Intcme. is called a da,a^cnn. The datagram 
headercontainsafieldti^tisusedtodesignatetoprotpcolattonextleveloftirestack. 

The lANA^ f values for UDP and TCP are. respectively. 17 and 6. Ibe figures below 

0 show how to payload of different datagrams can be intended for UDP and TCP. 

depending on to value of to "protocol" field m to datagram head«. 

AS mentioned abovctostimdard UDP header is eight (8) bytes in length, consisting ofi 



• source port (2 bytes) 

• destination port (2 bytes) 
25 • payload length (2 bytes) 

• checksum (2 bytes) 

2 IAN A (Internet Assigned Numbers Authority) 
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In to ccmv^ittonal «^ of OTP, fte source and destoation ports are lANA-approved 
numbers associated wi4 processes execnting wittin fte sender's and to receivers add«ss 
spaces, respectively. Ttere is curr^rfly no assigned number for to present automoOve 
telemetry appUcation. Tie present system uses to number OxOA (integer 10) to sp^tiy 
theATPport.^ 

.-^■„.,„,...lv imp Header - In to application of automotive telemetry, to 
overhead of the UDP header would consume wireless bandwidth witout providing any 
significant advantage to to pro«,col in tenns of fle^bility or reUability, Both to source 
and destination ports can be constrained to usetosame number. The payloadlengthcan 

be derived ftom fields in to u^lying nehvo* packet or data liric fame in wtach to 
UDP segment is encapsulated. Finally, to checksum can be viewed as redundant, smce 
to underlying data link protocol(s) should inc„n>ora,o an integrity check of to data 
Stream anyway. " 

Given to need to minimize wireless bat^width consumption, to UDP header is . in one 
embodiment, reduced to 1 byte in to implementation herein of to moWe 
communications protocol stack, which is iUustrated in Fi^ *. The value m thts byte 
(OxOAorintegerlOidentifiestoATPportatbothtosourceanddestmation. 

^^^^^^^j^j^j^afcllLay^ATP resides conceptually at to Session Lay- It^a 
■eouest/response mechanism, similar to Simple Network Management Protocol (SNMP). 
0 whichensuresti>atforeverymcss.gefiomeitoramobUeumttotobaselocationorvtce 

versa, tore is always an «=knowledgemen.. As such, exception reports ftom vehtc es 
eamro. be discarded by to mobUe computing platfonn until flte base system has 
confirmed tot toy have been logged to a "persistent storage" database. 
. -n. design philosophy of ATP is based on Simple Network Management Protocol 
,5 (SNMP) which enables remote di^sfics and configuration of communications devices 
■ and is to de-fiu*o standard witi>wMch elements of to lrtfemetinfi^stn»=t„remu^ 



3 This number is, as yet, unassigned by lANA. .^^^ . incoroorate integrity checks in the 



acase. 
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. comply A comparison can be made between remote diagnostics of communicatioos 
devices and mobUe vehicles. Tlus is iUustrated graphicaUy inFigwes 5(a) and (b). 
In SNMP me "manage entity" is typicaUy a comnnmicadon switching device such as a 
bridge or neuter. This managed entity implements an "agent". «hich is a softv™« module 
^ible for retrieving requested information and inte^ng «.th the remote 
.^er" through an hrterface . *e communications pn.toco. stac.. Figure 5(a) sho^ 
level of flns stack is SNMP. which is essentially a combination of the Sesston 
snd PresentaHon Layers. information that a remote manager may r«.uest rest es m 
a. Management Infomtatlon Base (MIB). which is a local repository for operaUonal da^ 
coUected by the device drivers controlUng flie h^dware interfaces tp *e e^Cemal world 
("CommunLations Modules,. For ins.ance,arou.er with an Edrernet adapt, ma^^^^ 

statistics reporting the number of inbound and ontbom^ ^mes — g the Eth^ 
interf^e. this information is cached in the MIB and is reMeved by .he Agent on behalf 
of a remote Manager which has issued a request 

i . in case of ATP, shown in Fig«e 5(b) below, *e entity equivalent to *e SNMP 
Manager is called a Mon,^r, and the ma««ed entity is a vehicular on-board con.pu.ng 
device inters to various data acquisition moduW. This is called lo^ 
repository aWgnostic Infbnnadon Base (DB). The informahon cached m Dffi 
originates f^om various sources such as ^ ECU diagnostic port, analog and drg-tal 

0 sensors.GPSteceiver,andsoo..Ttothreeexamplesshownina.efiguiear.: 

., sAEJ-1979 (diagnostic test modes required to OBD-n) 

• GPS receiver 

. direct analog and digital input channels 

™sisbynomeansaneKhaustiveUs.of.hepo.iblesourcesofda..0.herexamplesare: 

• SAE J-2190 (recommended supplement to legislation) 

• SAE J-2178 (Normal Vehicle Operation) 
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• SAEJ-1708 (heavy truck and bus) 

• SAE J-1939 (successor to J-1708) 

gj^^^^3^^^_MTMes^^ - -nie SNMP message consists of a header^ and a 
Protocol Data Unit (PDU). The header contains two fields: 

5 • Version Number 

ms specifies the version of SNMP that is being used by the originator of the message. 

• Community Name 

TOs serves as a primitive meftod of authenticttioiL Managers belonging to a eommvmity 
are said to exist witlnntlie same administrative domain. When a management agent 
,0 receivesanSNMPmessageftomamanagercontainingacommunitynameftrt.tdcesnot 
recognize, it does not participate in tlie SNMP operaUon. 

I„ ti>e present system, it is preferable to eliminate fields that are potentially redundant to 
order to r«iuoe the consumption of wireless bandwidth. This is tt« ease «th the 
community name since, as wiU be shown, a much stronger form of authentieatton ts 
15 .equired at the presentation level (i.e. the layer above ATP). A vision number wUl only 
become necessary once ATP evolves beyond the experimental stage. 

^^^^V^^^Os^mm ■ -n.- test of the SNMP message is fte Protocol Data Unit 
(PDU). Therearefcur(4)basic.««sofre<,ues.PDUdefinedintheSNMPspeciflcahon 

[1]': 
20 • Get 

A manager uses a Get PDU to retrieve an item firom an agent's MIB 



. ^epresentvcrsionofsuchadevLceiscalledaUniver.^^^^^^^ 

SNMP. The full co'^Pl^'^^.llr " Provides security features. The 

extends the functionality .P^MP, and a set of ^^^^^^ complement of specifications 

term "SNMP specifications" is used in this document to *° " ^Ip. 
p,S)ided in the KFC's published by the Internet Engin^nng Task Force OETF). 
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• Set 

A &f PDU is used by a manager to set a value in an agent's MIB. 

• Trap 

An agent uses a T^ap PDU to send asynchronous notifications or "alerts" to a manager. 
5 The manager does not acknowledge these notifications. 

• Inform 

MMormPDUissinulartoaT-rop PDU. Any SNMPentityCdfter an agent cramanag^ 
oonununieating with another manage.) may use an PDU ^ ^ 

notifications. In contrast to a Trap PDU. the receiving manager must acknowledge an 

10 Inform PDU. 

Before their use is ex^ed in the con.^ of — ve telemetry, the ac^ format 
speciflcationforfteSNMPPDU-sxvfllbesmnmarized. Figure 6 mus.ra.es .he format for 

Get, Set and Response PDU's: 
15 • PDU Type 

Tlis specifies ate type of PDU. TUs is eifl.er one of the four request PDU types alteady 
described or a response. 
• Request ID 

«s is essentially a sequence number for the PDU. THe receiver of a request PDU uses 
ao this in *e response PDU so that the sender can match the response wr«, a prevro^y 

«ar, fiitPT mit dunlicate messages, ims 



ttansmittedrequestltal^ensuresthatthereceivercanfilteroutdupUeate. 
. is particularly important in mobile wireless netwo*ing enviromnents. wl«re transre^t 
condidons render mobile nodes frequentiy "unreachable", which causes the sender to 
.^retries. In this kind of scenario. Are probabUity of duplic*e messages amvmg a. 
25 the destination is very high. 

by later versions of SNMP. 
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«s is shown m figure 7. A revues. PDU, encapsulated in a datagram, is roated to a 
„.0bUe asen. *rou^ a gateway to a mobile network. I. is d.en wrapped in a moW. 
•networkpackrt and routed to fl»moWe agent teou^awireless link torn the closes.^^ 

base station Whereas mobUe agent may receive the aixlink ftame contammg the 
5 packet, the RF base station may not W .te acknowledgement *at is «tted m 
espol Atter the r«,uisite timeout period, ^e RF base reports back to the mobUe 
nelk gateway that .he mobUe agent is "unreachable-, men this report . propagated 
back to the sender (ATP monito.), the message is te^ansnutted. 

• Error Status 

10 -nnsfieldisusedonlyintesponsePDUs. i, indicates one of a number of errors and error 
types. 

• Error Index 

field is used only in response PDU-s. It assodates the error (if applic^^^^^ 
of the "variable bindings" encapsulated in the remainder of the PDU. 

15 • Variable Bindings 

is the data field of flie SNMP PDU.. Each variable binding is an associadon of a 
p^c„larins.anceofamanagedobJe«.whichispartoftheMIB.with:i.c,^t^^ 
U the excepacn of Get revest PDU^s, tor which the value . .^ored^ The Objec^ 
dentifier (OID) field id^flfles d>e object instance. The value of the variable ts encoded 
,cc«ding,ofl..ripleT^y(t«». length. value). whereon, specifies d.e datatype. /e«.,. 

is the n^nber of bytes m which the value is represented in the subsequent s«am and 
contains the value in fcngr.by«.Tias encoding scheme foUows the prances. ^ 

in fl.e Basic Encodmg Rules (BER) of the Abstract Syntax Notation language (ASN.l). 
ASN..isanISO-specifiedlang«age.hatisoftenusedtodefineda.aexchangepro|ocols« 
the presentaUon and appUcaUons layers of the OSI model. Its abstract quahtyena les t ^ 
be independent of the different data represen^dontechnitr^s^a, can be encount^^^ 
differrcomputingpUtfbmts.Ofconrse..hem„re.bs,.aot«.syn.axfor„ 
„ the more overhead is required when these strucb^ are serrahzed m a data 



20 



SUBSTITUTE SHEET (RULE 26) 



15 



20 



^ over a coa>m™ioadons network. For tUs rea^n. SNMP uses only a su^ 
ASN 1 (speoilicaUy a subset of the BER) in order to restriet the overhead assoetated wtth 
fl«eneodingsdremeandtheiefbrepreservmgbairiwidthon<helnle.net[2].p] 

In AW. still with the objective of preserving bandwidft (whi* is all fl>e more imporUta, 
in fte mobile enviromnent of AW) a ftntiter res«Hction may be imposed on the encodmg 
schemeby eiiminatingfte,..^.fieldforaUbut variable le^strings.™^^ 
^ detailed format of the variable bindirrg int.. previous Ulusttation of the SNMP PDU 
format. Only the field ia used. receiver must infer the length of the v«/«e field 
from the received type. 

MS same format has been adopted, in .r. embodiment, as a model for the ATP PDU^s. 
However, in order to limit um«cess^ use of bandwidth in the wireless envtromnent. the 

following exceptions are made: 

1. The£™r»<.««and£™r/n,iexfieldsarenotpresentin*ere<prestPDUs. 

2. The value fields for the variable bindings are not present in Get PDUs. 
3 Tl« lengths of aU fields inthePDU's. including theOID and value fields infl^va™^^^ 

bindings (excluding character strings). ^ implicit; i.e. fl.ey are not explicitly encoded m 
the dalstre.m as,pecifiedbyASN.l. The lengtl. of alltireheader fields are restr^^^^^ 

one byte. Tte leng* of OID fields is .wo bytes and the lengths of ^ vartable bmdmg 
values are dependent on the value type, which is encoded in one byte. 

^uirements of ATP. Oe. PDlTs are needed when an ATP Monitor wants to retoeve the 
elnt values for a specific set of managed objects ftom a vehicle. An example . 
iUus.ra.ed in figure 8. A vehicle owner could obtain, fiom a fixed-lcation 
workstation, the veMcle's GPS location, engine speed, road speed and engtnej^^^ 
Bofi, the rcues. f. aU of this data and tire response fiom the vehtde ^ntanung all *e 
guested values would be encapsulated witiun a smgle ATP message and a u„ftagmen.ed 
network packet. 
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Tl, JV<^ PDU «m be med » send even. repcrU ftcm *e vehicle for wh.eh 
^w,edgen»n« ^ no. required. A mncal example wodd be a rec^ GPS 
positionreport. Applio«ionso«h™re in to oa-board device' could gene«= a 

Trap PDU wi* flre GPS position a, » in.erval specified wittun fte data struck for to 
5 OPS "managed objec.". -fte purpose of *is reporting would be «> track a veMde m r^- 
toe nrerefore acknowledgement ftom to Monitor are superfluous since to sender has 
no reason to re-transmit GPS positions that become immediately stale. 

The Inform PDU. which requires acknowledgement^ is to mechanism to. is used mote 
commonlymATP.osendasynchronousev«rtrepor.fiomtovehicle.-n«se.vemscan 

10 correspond to: 

. Regulatoryexceptions(e.g.emissiorxs-relatedeventsre^^^^ 

. Mainteriaiice exceptions (e.g.feultcoriditions requiring to^ 

inspection/validation/repair) 
. operational exceptions (e.g. use of to vehicle in an unauthorized manner) 

15 Since an acknowledgement is required tor tins PDU, to on-board mom«>ring agent has a 
„«ansofdet«mmingwhethertoeventrq>orthasbeenloggedinadat.base. 

The S., PDU is used to remotely change to operating par»neters of to on-board device. 
IMS conld be. for instance, to ti^hold level a. which a re^atory exception oocnrs or 
^ interval of mrsoUcited GPS position reports (for a tracking apphcation with Trap 

20 PDU's). 

^^^..^^.^^Sm^^^- The Mm to which SNMP provides access is a 
^Uection of managed objects which are organic hierarchicaUy. as shown m fl^. A 
„^ed object " is one of any number of specific characteristics of a managed dev.ce. 
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Managed obje* are comprised of one or n««e object instances, which are csscnUaUy 

variables. 

Figure 9 iUustra.es the MIB hierarchy as a tree, the levels of which are assigned by 
difier^at organizations. An object identifier(OID)uniquelyidenUfiesanaanag«iobj.d.m 
5 this hierarchy. The top-level Offi's belong to ditferen. standards organizations, wtale 
lower-level OID's are aUocated by associated organizations. Tbe OID is formed fton. the 
sequ^KC of ntnnbera corresponding to the nodes through which a managed object can be 
Kachedfiomtherootofthetree. For example, the sequence: 

1 3 6 1 a 

,0 identifies the MIB-2 object, which is the MB ibr entities 4at comply wiflt the 
specifications of the TCP/IP protocol stack. Ita fuU object name 
iso.idenafied-otganization.dodmtemetjngmt.mib-2 

Su^e ^ .Hi. MIB is n^moinea on a renu,,. rouur .UH interface, io several 
^«o* Tke object represerUing these interfaces are maintained in a ,aUe. eacH of 
,5 .Hose en^ is a colUCion ^^les associated .i,H network interfaces. Suppose for 
instance. ,Ha> «n SNMF ntana^ wanted ,o retrieve tHc number of octets received stnce 
,Helas,sU^-up)on,hcfirs,net.orkin,c,face.THeOmidenHfy,n,.Msotjeo,^^^^ 

1 3 6 1 2 1 2 1 10 

and the object name wotild be 
20 iso.identified-organiza.ion.dod.internetmgmt.mib-2.inter&ces.if»able.»^^^ 

A similar arrangement is contemplated for fire hierarchy of the Diagnostic Information 
Base, -rae question ti^t arises is whether a DIB sub-tiee should branch out fiom tite 
^ node or whether an SAB sub-tree should branch out ftom ti>e Identified 
Organization. It is evident that these two options would appear as shown in Ftgure 10. 
25 Tbeillustiatio„makcstiterootofti>enews«l>.ree.houldteti.eDlBnode. 

since ATP is a (proposed) protocol which operates a. ti» same level as SNMP wtthm the 
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Irtemet ^ of protocols, i, is atao ckar tot the DIB should exist witl> the sub-tree 

Starting at the Internet node. 

I. is not evident how the DIB could exist widnin a sub-tree vrtth its root at fte SAB node, 
withom a duplication of tte Interne, node. Ms would be a violation of a.e nde that any 
5 node on the hierarchy can be uniquel, identified. Therefore, it wuld appear to be more 
logical that the new sub-tree originates at the ATP node. 

AS mentioned previously, the OlD's in the variable binding of ATP PDlTs are encoded in 
a fixed length of two bytes. TWs means that the entire parent hie«rchy of fte object .s not 
included to which the OID refers. The prefix 
10 1 3 6 1 2 8 

coirespomUng to the object ncme 
iso.identified-organizadon.dod.intemet.mgmt.dib 

an mucupar, of.acH OID. Onfy ,he portion ielo. ,^ DIB ™* ,s seriaU^^ ani 
transmitted over the network 

,5 IteO^m- Atthehi^ 

user interface allowing the installer (or eventu^y the driver) to speci^r which sources of 
internal vehicul. data should be accessible to which remote "cUents". next se«.on 
explains how the identity of any remote client can be completely authenticated and how 
to subsequent data exchange between client and (vehicular) s«ver can be made secure 
20 against any eavesdroppers. 

Security - With ATP, to agent should have to authority to accept or reject requests firom 
the monitor, based on to namre of to request and to identity of to monitor. For 
instance, a request fiom a .mote monitor to report to current OPS — 
considered an invasion of privacy if it originates ftom a location not cc,n«n^ by t^ 
as vehicle owner. Similarly, a request for OBD informaaon (SAE M979) could also be 
r^eoted. unless it originates from to moni.or(s) aud,ori«d, according to to User 
Configuration. 
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y, order .o meet ihese rcqmreme^ »mm»nica«o„s Unk betwe^ a.e mobde agen, 
;„d4emo:u«.rn.us. provide bofl>fer privacy a.^a«*«n of *ere,u^g»^^^^ 
U teMoniU.. A. ideal ft.n»wo*for«is is *e secure socket l.yer(SSL)pro«.co. 
SSL was developed by NCacape a«i has become tte d.fac« .^ndard f-^'«-»>'"*^ 
, security between client, and servers in the Wenret ^ pa^icnlariy tor Web-bas^^ 
conunercc-. SSL defines a h«>dshaldng protocol aUo^g for authcnttcaUon of ette 
P^by the oa«r using pt^Uc-keyet^rypUanmethodsv^chareeflecdvelyu^ 

Konnally, SSL operates on top of TCP/IP. ^ch constitutes the underlying transport 
ntechanismforWebtraffic. Hov>^. because of the nat«e of the telemetry apphoano,. 
0 ATP uses the UDP/IP stack. The lower edge of 4e SSL record layer must lta«&.e be 

adapted to intetfece to the UDP transport mechanism. 

Figure 11 sho« *e security mechanism of SSL introduced between *e ATT layer and 
are presentation layer, where ^ Protocol Data Unit (PDU) is parsed into u^™^ 
re.^ for specific source of data. The securi^ layer acts as an effectrve flrewali 
15 againstunauthori^intruders. K authenticates the remote monitor and maintams prt^^y 
L ate contents of the subsequent PDU^s that are exchanged across the sess^u. The 
«erfacebetweentheSSLhandshaki„gprotocolanda»presen.ationl.y«^^^^ 
a mechanism for SSL to precede fl« announcement of a recetved PDU vnth an 
ideotificationofanaJthenticatedmomtorrequesti.«informaBon. . 

20 Thismechanism.asv«Uasthe,ubse,uen.da«eKchange.ismustr..edbythese,^ 
Figure 11. 

The individual steps of this sequence can be described as foUows: 
,.TheMom.or'spresentationlayer«,tifies its security layer totitwantstois^aearequest 

to the Mobile Agent. 

25 The SSL Handshaking must now take place between cUen. (Moni««) and server (MobUe 
Agent). 



'2 See the specification in [4]. 
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I CQT T?<»<iotd Layer to encapsulate the requisite 
2. The SSL handshake layer asks the SSL Recora i^y 



3. Il.e SSL Record Layer sends an asynnnetrically encrypted message (pubHc key 
cryptography) to the other side. 
5 4.Tl«SSLR»oraUyerdeUv«sadeoryp.ed,nessage«>*eSSLHa„d^elayer. 

Step= 2-4 are repeated u. ^ di«otions >m« the authet^cation of the eliet^t has beea 
established. 

5 once the Mc.d«,r has been auU.entiea.ed. SSL reports its identity to flte presentation 

iayer.-^-^-'-*-^*-"™'"'*^"^'^"''' 
10 the User Configuration. 

e. The sec^ty iayer on the Monitor side rep«s to the presentation layer «>at the 

authentication has been confirmed. 

7 The Monitors p^sen^ttion layer sends «.PDU to security layer tbr^ssionpri^^ 
Lrypeon. T.e encryption is carried out ^th a synnnetrica. one-tnne .ey exchange^ 

,5 hetL the parties during flte SSL handshaking (and which ensnres the pnvacy of the 

exchange). 

8 TheencryptedPDUis"«nsnu»ed-.otheMobUeAgentIno.herwords.itispassedon 
downthroaghtheSessionLayeroflheMonitor'sprotocolstack. 

,r • * A= CQT Rpford Laver of the Mobile Agent, it is 

9. When the encrypted PDU amves at Ihe SSL Record Layer o 

20 decrypted before being handed-off to the Presentation Layer. 

10. m response fro. the Presentation Layer is sent to the SSL Record Layer, 
response may be: 

• data requested by the monitor 

. aeonflnnationthat.c«mm«>dser*bytheMonitorhasbeenexecuted.or 
25 . ar^eotionofei.l»racomn.andora,e,uestforda.aheeansethcMonitordcesnot 
have fte requisite authority for the re^ or connnand. 
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„ -n« SSL Layer encrypt, me respc^e ™d> fte syn^eWcal .es.i* ^ ^ 

back to 4. Monitor (i.e. tough *e protocol ..ack starSng ^± the MobUe 
Ageirfs Session Layer. 

lilt-cMonito^sSSLRecordLayerdecryptsthePDUandhandsitofftothel^ion 

Layer. 

^o.etba.aIUrpax.ofthis.,u.ceco,.dbecarrieao,.in.hetevets.air^Sup^^ 

.hat the Monitor r^resents an etnissions control regulatory agency and tW a MobUe 
^^e^treceivesareciuest every year ftorn .his Monitortoreportannon-cornpl^ncee^^^ 

1 Mobile Agent nray respond with a positive ac.a.owledgen,ent - J— - 
Uyer. U. an acccp«.ce of the truest. For Ore rest of .he foUowu>g 365^y penod, all 
^ception condidons vriU cause the MobUe Agent to initiate communicaUons to report 
^^JcorKUtions/Tl^ request vviU therefore en>anateftonr the Mobile Agent^vh^ 
response fionr the Monitor «U indicate that the exception report has been noted and 
lo^ed to pennanen. storage (lire U^BD can be configured to keep these excepUon 
.^rts in Flash nrentory untU an acknowledgment is reived 6on> fte Monrtor. ms 
elures that exceptions that occur whUe the vehicle is not within coverage range are not 
"forgotten"). 

VEHICLE-TO-VEHICLE TELEMETRY - M^mV^m^^m^^sALS^il^^^J^ " 
OBD-m is an example of telentetry consisting of a mobUe s«ver and a fixed-location 
client. Al» envisioned is the case of a oUent-server relationship between ^.o nrobde 
.ehicles. A data hnk between two vehicles can be estabUshed usnrgti. ^^o^ 
ne^orm capability of the IEEE 802.11 specification for wrreless L^. A«ro^ 
networks in wireless LANs are created without a central coordmating n^de. 

point. Figure 12 illustrates the distinction between an ad-hoc wrreiess 1^ and 
one with an access point. 

By using different spread spectrum both types of networks can coexist on the 

sle hardware platfonn. access point provides tire vehicle witir — hvr^-^ 
Tde Area Network (i.e. me intomet) but is not re^fc^-ad hoc ne.wo*.The^ 
hoc network enables vehiclestoestabUsh logical links withtheirneigl*ors.whrch can be 

used to exchange critical operational information between vehicles. 
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Aahocn*™rkso«b.cxe,.ed»smg.sche«.embcdi.dherem.ha.perm.,seachveta^^ 
^ ^ a real-time in«ge of i« "neighbothocd" This neighborhood can .nclude 
vehicles up «, five hundred yarfs in hofl. the forward and rear dictions. ^ una^ 
maintained wifl^ each vehicle changes dynanucaUy with changes ur the surroundurg 
conditions. 

Tie ATP protocol stack can be us^ for vehiole-,o-vehicle n^essaging in ataros. the same 

^ J i. is used to intact With r»„. diagnostic cUent. ^ 

security resections cannot apply intius case Since an vduclesn^stnecessanl, and fiedy 

exchange mfbrmatton. This is aiustrated in Figure 13. 

-Vehiole-to-vehicle 

Transport Systems (ITS). Platooning is simply one example of what ,s referral to he^ 
^as ..clus.erin.emgence..on.heroad. A elus« is the aggregation of vehrdeswAm 
a nei^borhood. Since 4e neighborhood of any vehicle consututes a flurd network 
> «,pology surrounding it. the membership of the associated cluster is dynamic 

. ^ exchange (or the br^casting) of information within a duster has value in ^ of 
both road safety as w^ as traffic management aimed at reducing congestron. In some 
respects, fl^re is an artificial distinction between these a«as. Better traffic management 
shlld result inbettcr safety and Vice vers. Tire descriptions of the following appUcatron 

:0 areasdonotdistinguishbetweenfliesetwDpmposes. 

8,^^ . vehicle on-board systems such as cruise control or cockpit e,ec«onic 
t^^systems can benefit ^m a variety of inputs, — Z"^ — 
avoidance radar as weU as vehicle-tn^vehide information exchange ftctittated by ATP 
with ad hoc networking. 

a5 Adhocnetworkingistherefpreseenasprovidingasupplementarysetofinputs/s^eesto 
control/information systems. In some instances, these inputs/se^ces may ^ 
complementary to one another whereas in other instances tirey would over.^J« 
i^ce. in the case whe« vehicles are IEEE 802.11-enabled. radar can complement ^ 
^ networking by providhrg neighbor information for immediate adjacent vehrol^. Of 
30 course, if these vehicles are also IEEE 802. 11 -enabled, this functionnUty overlaps ti^ of 
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802.11 is insignificant^^. 

The \^ use of »obUe da«. co— .ions fo. re,no.e o«-W data acqui^tion 
• ,„ a need for a standard architecture enabling interoperabiUty of modules 
rj^^erartleme. aeross.de area— s^ T^^ 

potential for widespread use is ^less On Board ^^-"^T!^"^^ 
Cisann™berofo«^appUca.ion.ine,ndinsve«cle„^.enance^d»^^^^^ 

^™ of eotn^anications network management, where nodes such as bndges ^d 
, ::lTa:Lremo.e.ydi,gnosedbyamanasementen.i.y.p™^^ 

nmotevebicuiardiagnostios. The specifications of the Simple Ne^vor. Man^ement 
"^are^^efi^usedhtnovelandune^W^ 

LlmotiveTelemetryP-otocoUAlP). : ^ "7^ 

« enables client-server reWonsbips between on-board dragnost.0 agents and 
5 WtorsMocatedanywhereinthenetwork. The SSL protocol is layered ab^ve ^ 
ITl security. The same protocol architecture, minus the security, can be Uyered on 
:;:™In-basedadhocnetworksforappUcationinintemgent^^ 

(ITS). 

NETWORK NEIGHBOURHOOD 

The concept of a n.i^^f^" been borrowed as it is used in *e 

ioirgL sense to characterize adjacent nodes on a data linl. If node A can re^h 
r^n^,)nodeBwi.hou.traversingacommunicationsbridge.*enAandBaresa.d« 

r: ie neighbourhood, ^s is Ulus.ra.ed in .igure 14 .^oh d^t^^o^ 
,5 Bnks competed via a bridge. The da« link on the right is defined by 4e I^E 80W 
«^-fi-tton.whichiscommonlyusedforwiredI.calAreaNetworl.(L^^ 
montheleftisspecifiedbymEESOZnwhich is Wireless LAK As« 
■ ^ ,4 A, B and C are nei^bours on the wireless LAN. whereas D. E F and G ^ 
neighbours on the wucd LAN. Mftou^ 
30 neighbourhoods of both *e wmless and w»ed LANs are 
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b«ween the .odes, not by phyrical distance. If two nodes share the san>e 
medium and the <paU,y of the signds between them is acceptable (in temts of error 
leveb). then they are topologicaUy in the same neighbouAood or ,^ace«t. 

; to the case of an intelHgent highway network neighbourhood, an additional geographic 
criterion can be added, if dedred. to fte determination of adjacency. By comparmg OPS 
position reports of other nodes on *e data link with its o^t GPS position, each node can 
filter out other nodes which are outside of a specified geographical threshold and therefore 
not relevant to the operation of the vehicle. 

Tta foregoing description aUows up to put forward a definition of an ITS Wi-Fi 
Mi^tbourhood, from the perspective of a single node. 

An ITS Wi-Fi neighbourhood is a coUection of surrounding IEEE 802.1 1 nodes, sharing a 
15 common physical medium (i.e. a specified direct sequence spread spectrum channel) as 
weU as ti« timing parameters for medium access control, and wititin a relative geographrc 
position tiM is significant .„ the safe operation of a vehicle on any type of pubUc roadway. 

REGISTRATION ON THE NETWORK 

TheIEEE802.11 specification defines timing parameters ti«. are used in conjunction with 

a timing synchronization function to coordinate access to the medium; i.e. to mmmnze 
con.entionfortirechannelandtoreducethepossibili.yofcomsions.Nod.scannot,^the 

medium to transport data until ti,ey have received tire apptopriate "registration ftames 
25 ftom nodes titat are alre^y part of ti>e network. Registration ftames contam tire 
information needed to correctiy operate on to medium, including a time stamp aUowtng 
flie new entry to synchronize witii tiie existing nodes. 

to 802 11 tire mettKKl used to coordinate access to tire medium is called CanUr Sen^ 
30 Mume Access CoUMon A,.mnc. (CSMA/CA) which is similar to ttte method 
usedin 802.3 (Etiremet). I. is based on tire ideaofsniffing" the channel foraearr-erprror 

U, tian^on. It tire median is busy, the node witir data to send enters a randomly- 
computed waiting period before retrying, which minhni^s the likelihood of simultm^ous 
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^e, by multtpl. .odes v.ai««g *>r channel (and *e resuldng »gridlocr.*at ^ 
would create). 

The 802.11 specification calls to a Cis^nln^^ ^Sr^on fi^ncUon <pCn It also 
defines a contention-ftee .nechadsm ^ch is oaUedpoWcoo.— >.«o» ^F, 
„ DCF is th. deftnl. mode of opetation. PCF has heen n^ avad^le ^h^d^ 
special scenarios, as in «>e case of tinxe-critical traffic snch as " « 
PCF is provided through a fixed access point, which, in the case of ITS, would take the 
fonn of a roadside base station. 

vehicles wishing to have access ,0 the Internet will register with roadside access points 
^ the channeKs) allocated for tins application" The P^^™ 
Jri^ audio and video, or for VOff (Voice Over IP), may re<,uire the PCF method of 
ohanne. n>anageme.t However, the ad hoc network of vehicles shamtg the sa« 
; ^l^hourhood wiU use DCF «. manage its channeKs). Since DCF does not rely ^ 
^ of a "master" station to coordinate access to the medium. fi» ad hoc netwoA 
d<«s not re<iuireanMdsideinftastructure in orfer to flmcUon properly. 

«s does no. preclude the use of a roadside inftastrucn^. Even if Intenret acc^ and 
other services areopfional.bascstationsmaysanhe.e<^foravar.etyotancal^^^ 

^eUons, including differenfial OPS heacons. geographic orientanon wrti> respe^ 
highway system- electronic toll coUection. electronic road stgnage and travel 
infonmtion. 

25 Theregrstrafionmechanismitselfcanbeoperatedineifi^rapassiveoranacfivemode. 
Both of these methods are described below. 

Passive Registration 

30 to«aepassivemode.acandida.enodelis^sfora»e<.onfiamefiomanexisti„gnode.In 

ITS and Internet functions. 

" See Wi-Fi Channel Selection. 
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3a hc«^a..«ds«ng«od«— -beacon fi^^espeno^ca,..—^^^^^ 

entering the network to synchronic ^ e>dsting nodes for channel management. A 
".ante signaU^startofacohtenaon-ftceperiod. during which al, other nodesrn 

r ighhonrhl ae.. .r^n^ssions so th. new nodes wishing to _ .h.r 
^If can do so. Both the interval between he^on tanes and t^e subse^n t 
rinrion -^^pe^odareconagnrahieparantetersthataretypicaUv^^^^ 
2 se^nds a»i 100 ms - 0.5 seconds, respectively. However as wOl be seen mthe next 
eTr^^erernaybeseveralhundredveMclesin^^sarneneighhonHrood^pam^^^ 

cTgeld highway conditions, which wonld render these se«ings in^sstble. Incre«ng 
rJ^allelbeacon^esisoniypartof*es„luaon.Fig„rel5mns.ra,^.h.,f 
reT^eoflOO vehicles were to transn^tbeaconftanresat intervals oflOsecondseach 
ZnIg*es.^otalOOn.scontention-fteeperiod.,herewonldbeno^leftdnnng 

the 10 second period to transmit any user data, 

; complete soludon Ues in the ftct that *e ITS ad hoc ne^»ork nodes ^° -'"^^^^ 

IJotiate any of the logical management fimctions of assoCaUon and a.^n,.ca.o^ 
negouaic y . . , «n7 11. Association is the 
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neeotiate any of the logical manaBcx^^x.. x , 

; L in^e m«.nm access control (MAO layer of SOZU. — " th^ 
lhanism whereby one re<^ «pUcit recognition flom another n^e. 
ristrncture network, requests arescn.toanaccesspoin,«Hchs.oresthea^^^ 
Siting node inalocal table and sendsaresponseftame. Tie address table mamtam^ 

rriss point controls.whe.her packets desthred «>r specific ^^^^ ^ ^ 
trLsmitted.Ifnoassociationhasbeenestablishedft.anaddress.nouserd«aw.nbese„t 



to it. 



However, as explained in the s^Honentit,edNeighb.urDiso....y,m<»tof*e«s«^ 
"In .dhocnetworkis sent to *e broadcast address (i.e..o^«odes).forwht<^^ 
■ -^H There are some appUcations in which associations with 
these wl be only with the physically ad.a^ 
^t^hnodeshouldonlyne^ateassociationswithneighbonrsinsideaprescnb^i 
wherein *e driving manoeuvres of those neighbours are Significant enough. 

:^u„icastmessages (U- addressed « specific destinaaon node. Since ^^^^^^ 
^receiveafi>rgreat«numberofbeacon^.sftomneighbou.-thw^ch.d^n. 

associadons, the oomenti^n-ftee periods following these beacon fiames wtU be 
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essentiaUy «a*d. In order » preserve baodwidft. ttie conte«io„-&ee penod should be 
^ueed «. a mmimun, allowable value (say, 1 ms) and die negotiation of assocrations 
should be trigger^l no. by 4e reception of beacon ftame^ but by conditions deKnnmed 
tough the Discovery process, vAich is described in the next section. 

Au,Hen,icaHon is the p»cess «teeby the requesting node is granted pemns^on «, 
conununicate using a synnnetiicl encryption key. In the nS ad hoc network, 
auU^entication is not only not recpited, it is anti-thetical to ti,e conc^ of vehtc e 
platooning or "cluster intelUgence" because all parties must necessanly «k1 fteely 
exchange information wiliiout restriction. 

Active Registration 

Tl.e active registration method enables the candidate node to sendpr«6. ftames, which are 
: W r^^r^ o*cr node to respond, h, the "»* 

«,p„logy. probes must be broadcast to aU listeners, as ti,cre is no stngje "ode 'hat -n be 
JedSon to always be presentee, fixed access point, Ute IEEE 80a.nn.etsthatti,e 

^nsetoaprobeissentbytb.nodewhichtransnnt.edfl.emos.reccntbeaconftan.e. 

Tl,e facility of active registration enables us to minimize the use of bandwidth by ti,e 
transmission ofbeaconftames. suppose the interval between beacon ftames is con^^^^ 
to 60 seconds. Witi. a contentton-ftee period of only 1 ms after each beacon frame, 
platoon of 5 vehicles would use roughly .01 % of tire available time for beacon fiame 
broadcasts, and a platoon of 500 vehicles would use only 1%. 

The scenario witi. 5 vehicles U shown in Figures 16a and 16b. The average time between 
beacon frames is 12 seconds. Each vehicle m ti.e platoon is numbered »=cordmg to rts 
«,uence position tor transmitting beacon frames. Vehicle 6. entering on tite acc^ ramp. 
^ transmitting probe request ftames after vehicle 4 t^mits its 
30 orL to discover a new ad hoc network". Vehicle 4 responds almost .mmed.ately wtfl. a 
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probe response . 
NEIGHBOUR DISCOVERY 



The neighbour discovery mechanism is comparable to the concept of neighbor discovery 
protocols used for routing data traffic in network environments with dynamic topologies. 
The method is based on unsolicited neighbor advertisements that incorporate, as explamed 
previously, a geographic component. Tliese are periodic messages that each node 
broadcasts containing its GPS information, including latitude, longitude, speed and 
heading^'. 



m neighbour advertisements are used by each node in the ad hoc network to establish an 
"image" in memory, of the current configuration of the neighbourhood. Figure 17 
illustrates this concept, showing the neighbourhood image formed by the second vehicle in 
the passing lane. 

The tune interval between broadcasts, called the discovery cycle, must be frequent enough 
to maintain a picture of the neighbourhood that is accurate in terms of the relative position 
of each neighbour. The accuracy of GPS reports, in terms of the relative location of two 
nodes m geographic proximity to one another, is much higher than the accuracy of 
absolute GPS reports, since the error inherent in the processing of the satellite signals 
should affect all nodes equally. Therefore, the relative position of each node with respect 
to the other should, theoretically, contain essentially no error, enabling vehicles to judge 
the distances between them with a level of precision lhat is effective for the tasks of 
collision avoidance and platooning. For instance, Ihe position of a vehicle travelling at 70 
mph changes by more than 100 ft/sec. This would suggest a requirement for several 



^^^^^^^^^^^^^^^^^^^^ 

necessary to adopt the rule that when the "^^X^rS^^i on a^^^^ 

"depopulated", the vehicle must begm broadcastog ^^g^^^cLn&ng Neighborhoods. 

?=sTonsr^:iroo"^^^^^^ 

^ESSmt'iso be required. ™s^^^^^ 
expressways from those at grade level. 
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^es pe, seoona in ord=r «. maWain ao^y. However. U>e Wy of >^ . 
echoed by *e amount of data .raffle fluU is genera^d during d^very cycle, m 
^ to avoid channel contenfioo. This, in ^ is a 1^ of number of vehrdes 
are within RF range. i.e. the «<rig/.iorWpoputa<to». 

It should he receded, ho«ver. fl.ere is a circular reWion^p between all o, *^ 
variables. The nei^bourhood popuMon is a fin^Uon of ^ average speed of 
sunounding vehicles. The greater the speed, the smaUer the neighbourhood popuh^on. 
the^fore the smaller *e amount of data traffic m «re discovery cycle which allows S>r a 
greater frequency of updates. 

This can be iUnstrated by example. At 70 mph. the safe stopph>g dista^ is rougWy 200 
fet AssumingaUvehiclesrespectthefecommendMstoppingdistance^.amaxnnnmKF 

^ of 3000 ft » and amaximum of four lanes m*e same direcUon-. *c surroundmg 
neighbo»rhoodcancontamaniaximumof60vehicles. 

TO deterinmc the .o«l ^o^i of trfSc that is «ansmitted over the sp^ad spectrum 
oha»e..w. must firs. estabUshthctotalsize of each discovery packet. Thts.^^^^ 
Pi^relS.wMchdescribesd.proWstac.fi»m,h.ph,^.othesess.on(A^^^^^^ 
ItLpeotedihat all of*ere,«red user mformationaboye^e data hui. layer aEEE 802 

Logical Lh* control) can be compressed in» 8 bytes. The result is a ftame s.« a. 4e 
Physical Layer Convergence Proced«e (PLCP) sublayer of 64 by.es. Therefore. .hc .«..al 
amoun. of traffic in flie discovery cycle is 

25 64 X 60 = 3840 bytes or 30,770 bits. 

A. 11 Mbps- the data rate of .he spread spectrom channel should be able to support 
lertd diLvery cycies wi*in an h>.erva, of one second, even allowh^ some 



discover. ftan,cs » *e.™=d.m»l^W;F,C'^^^^^^^ 
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degradation of througlq)ut due to channel contention with such a relatively large number 
of nodes. 

In order to compensate for this change, the event queue of the "cluster intelligence" 
5 process should include a periodic timer that drives an update of the position of all vehicles 
in the neighbourhood, based on the speed and heading reported in their last broadcasts. 

Filtering Neighbour Advertisements 

10 Each node can limit the population of its neighbourhood such that only those neighbours 
that are close enough to have a potential impact on the safe operation of the vehicle are 
included. By filtering out node beyond this boundary, the size of the collections of 
neighbour "objects" in memory are restricted and the amount of processing necessary to 
periodically update any state variables belonging to these objects are limited. 

15 

Message Compression . . 

It has been stated that the GPS discovery message can be compressed into 8 bytes. This is 
accomplished by incorporating only the least significant 2 bytes of both the latitude and 

20 longitude^. These 2 bytes represent the fractional part of the rmrmtes portion of the 
reading. This is sufficient since one minute of latitude or longitude is greater than one 
mile, which is well beyond the maximum RF range of 0.5 kilometers. Therefore, a 
receiving node can easily reconstruct the GPS position of the transmitting node by 
substitutmg the degrees and minutes of its own GPS position for both latitude and 

25 longitude. It must also increment or decrement these values where appropriate near 
measurement boundaries. For instance, if a receiving node has latitude of 43 degrees and 
56'9982 minutes, whereas the message received indicates a fractional value of .0053 
minutes, the minutes value substituted should be 57 instead of 56. 

30 Figure 19 illustrates the format of the complete GPS discovery message. The speed is an 
integer value from 0 to 255 (one byte) and tiie heading is from 0 - 360 (9 bits) witii 7 bits 



» The size of tfiis message increases to 10 bytes if elevation is included. 
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of ftactional degrees. The leading byte indicates, in the most signiticant bits, the channel 
to be by the sender for broadcast on the next discovery cycle. This is explained in the 
following section. The other bits of the leading bylfi are reserved for future use. 

Wi-Fi Channel Selection^ 

The 802.11 specification for mobile ^pUcations calls for at least 3 channels of direct 
sequence spreading (DSS) which can operate concurrently without interference. However, 
through soflware-based configuration of the transmitter, more chamiels can be obtained at 
lower data rates. For instance, by allocating a single ll Mbps channel for high speed 
internet access, a larger number of at least six 2 Mbps chamiels can be obtained from the 
remaining bandwidth. This allows mobile nodes to separate ad hoc networkmg data traffic 
from infrastructure-based data traffic that uses roadside access points. Since there is no 
need for communications between vehicles on opposite sides of a median, it suffices for 
each node to monitor the chamiel used to broadcast discovery messages by aU other nodes 
travelling in the same direction. 

hi order to avoid unnecessary channel contention between vehicles travelling in opposite 
directions, the chamiel selection for discovery broadcasts can be determined on the basis 

, of heading. A simple scheme would be to allocate 4 of the 10 chamiels for ad hoc 
networking and to divide the compass into four quadrants^^ However, as Figure 20 shows, 
this would not handle flie case whei« a slight curvature of the roadway would result in a 
following vehicle listening to a channel on which the leading vehicle is no longer 
transmitting. This can be resolved by flagging the discovery message in a way that 

5 indicates to neighbours on what channel the next message wiU be transmitted. 

In other words, when a vehicle detects that its heading has shifted into a different 
quadrant, it should not immediately begin transmitting on the corresponding chamiel. The 

. ^Tn^dditionalchaBnelshouldbeallocatedforu^ 
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next message is transmitted on the current channel but all Usteners are advised of the 
channel that will be used on ±o subsequent message^^ Only the foUowing vehicle should 
switch to monitoring the new channel. It should also switch if it detects the heading 
change before it receives the change, of channel flag from the vehicle ahead. 

This vehicle enters a transitional phase where it may monitor a different chamxel than the 
one on which it t^mits. Durmg this period, the next following vehicle will receive 
messages only from neighbours transmitting on the "old" chamxel (Le. prior to the 
curvature in the road). It will not receive any Discovery messages. More miportantly, it 
vdU not receive any asynchronous event reports from several vehicles ahead m the 
platoon, hi order to compensate for this, it needs to contmuously scan both the "old" and 
the "new" chamiels until it receives a "next chamiel" flag from the vehicle ahead of it. 

Changing Neighbourhoods 

To establish the conditions under which a vehicle changes neighbourhoods, reference is 
made to the definition of an ITS Wi-Fi neighbourhood given earlier. The neighbourhood 
changes when there is a change in the shared medium. An example of such a change has 
already been described, when the roadway heading shifts to a new compass quadrant and 
) there is a staged transition ofthe platoon to a new Wi-Fi channel. 

In order to addiess this issue, the following question needs to be answered: how does a 
vehicle determine that it is entering an expressway without requiring the use of detailed 
digital maps? The solution is simple if the vehicle is foHowing another one that is entenng 
5 the expressway. It is the leading vehicle's problem! THe following vehicle simply needs to 
monitor the current channel for a "next chamiel" flag from the leading vehicle. Of course, 
this is a facile solution since it shifts the problem to tiie leading vehicle and besides, it 
does not address the scenario where there is no leading vehicle that is currentiy withm the 
neighbourhood. 

The answer is provid«J by the mechaoism for active n=h«,A registrahon mmg probe 

taken place using probe frames. 
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ftames When a vehicle detects that it has no one ahead of it, it must begin to probe 
whichever of the four, channels allocated to the quadrants of the compass in which the 
vehicle's current heading falls. Until it receives a response from some node on the new 
channel, it should continue to monitor tixe existing channel used for undivided highways 
and city roads. One of two possibilities wiU occur. 

. newneighboursarefound(throughthediscoverymechanismon1heexistiBgchannel). 
These could be moving either in the same or the oncoming dkection. Or even in a 
transversal direction. Their locations preclude tiie possibiUty that tiie vehicle is on an 
access ramp to an expressway.Inthis case, the vehicle ceases the periodic probes. 

. a probe response is received on the new channel. Tlie vehicle must prepare to switch 
channels and notify all its current neighbours tiiat it is doing so by setting the "next 
channel" flag in its next discovery message. 

Tliis scenario is reversed m the case where a vehicle leaves a divided expressway. 
Service Advertisements 

There may be cases where specialized nodes may provide streams of information that 
would be costiy, in terms of bandwidth, to broadcast in an unsolicited fashion. Instead, 
these nodes can advertise the availability of such services by periodically broadcasting a 
message notifying all listeners tiiat the service is available upon request Examples of tins 
would be a digital video camera mounted on board a vehicle or on a traffic signalization 
Ught. 

APPLICATIONS 

Safety vs. Congestion Management 

The application of ad hoc networks to ITS tasks has value in terms of both road safety as 
>vell as traffic management aimed at reducing congestion. In some respects, tiiere is an 
artificialdistinctionbetweentiieseareas.Bettert:afficmanagementshouldresultinbetter 

safety.and vice versa. THe descriptions of the following appUcation areas do not 
46 
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distinguish bestween these two piirposes. 



Event Notification 
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All nodes p^dpating in a. ad hoc ITS n-work are «qutoed to infcnn theit neighbours 
of any operational events that ntay be significant to a neighbouring vehicle, such as 
acceleration, brake appUcation, turn or lane change. ^. Ttese events should be reported 
as asynchronous notiflcoHons sent to the broadcast address. In other v«,rds. any neighbour 
^ is listening should receive a real-time notificadon of to event. For in^nce 
application of the foot brake would be reported not only to the foUowing vehicle behmd 
but to every other vehicle in the follovring platoon. Tte paction time to a brake bgW (.f .t 
is working) is typically in the range of 0.5 s«=onds. Wore, if the veMcle at the head of 
a platoon of seven vehicles applies the toot brake, the vehicle at to end of the platoon 
could recdve notification as much as 3 seconds before seeing to brake lights of to 
vehicle in front of it. 

All asynchronous event notifications should be repeated up to n times, where n is a 
configurable parameter of to EEE 802.11 MIB (Management tafommtion Base). 
Repetition of event notifications wUl ensure that foUowmg neighbours required to l«ten to 
more flian one channel (during to transition phase described in Wi.Fi Channel Selection) 
will have an opportunity to hear the message. 

Intention Notification 

Tte ad hoc network provides to means for vebicle-to-vehicle n^on ofinU,n,ion 
with respect driving maneouvres. A class of such notifications can be specrfied fliM 
require expUcit acknowledgements trom to receiver of to notification. (Acknowledged 
Connectionless Service of to LLC layer) These correspond to Se, commands tot can be 
issuedthrough touseof an ATP client service. By acknowledging tose notifications, to 
receiver mfcrms to sender that it is "aware" of to sender's mtentions. The state of 
knowledge of both parties can then become inputs to ib^ respective contml or cockprt 
electronic infonnation systems. 
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Figure 21demonstrates an example of a driving maneouvre that can be assisted by ad hoc 
networking. Tlie speed of vehicle A in the. passing lane is greater than that of vehicle B in 
the slow lane. Assuming that the speed of B remains constant, A can determine how much 
time remains before it passes B, using its own speed and the neighborhood position of B. 
When the remaming time equals Ihe time interval required for advance notification (Ax). A 
sends a unicast frame to B containing a notification of intention to pass on the left. If B 
responds with an acknowledgement, A is therefore able to provide the appropriate control 
or driver information system with a confirmation that the vehicle to be passed is "aware" 
of the intentions. 



Lane Change 

The intention to change lanes can be amiounced and acknowledged in a mamier similar to 
the intention to pass. The vehicle preparing to change lanes issues its notification to the 
closest following vehicle in the lane to which it intends to change. Again, both parties are 
aware and prepared for the manoeuvre. 



20 Merge /Yield 

One of the most interesting potential applications of ad hoc networking is the management 
of lane mergers and yielding on access ramps and lane closure on expressways. As 
Ulustrated in Figure 22, both the yielding and the merging vehicles are aware of each 
25 other's location and speed, which provides their respective cockpit electronic information 
systems with inputs to assist the driver in a smooth adjustment to the new conditions. 

IntelUgent Traffic SignalizationMighway Information Systems 

30 Discussed herein above is the capabiUty of Wi-Fi to support concurrent ad hoc networking 
and infrastructure-based communications. Whereas intelligent traffic Ughts would be part 
of the roadside mfrastructure, they would need to use the chamiels allocated for ad hoc 
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networking in order to be effective, since it is only these channels that are regularly 
monitored by vehicles. Using Wi-Fi, an intelligent traffic Ught could, for example: 

• transmit a "yellow light" notification to approaching vehicles 

. alertvehiclesinthetransversaldirectionofoncomingtrafficathighspeeds" 

• identify vehicles that run red lights^* 

On the other hand, highway information systems (electronic signage, automated toll 
collection, etc) should not operate on the ad hoc channels (unless it can be determined lhat 
substantial bandwidtix remains even under the most congested driving conditions). 
Vehicles could monitor these infrastructure chamiels as initiated and terminated by driver 
input functions. 



" If oncoming vehicles are not equipped f "^^^^^^^^^^^ request 
The traffic light wonld request the registration from the ^.j^^ thifwould create a 

would be authenticated, at the ATP level, as coming froin an authorized client. If feet, this womo 
deterrent that would probably eUminate the problem entirely. 
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CLAIMS 

1. A method of conveying vehicle operation data from a vehicle to a remote monitoring 
recipient, comprising the steps of: 

5 - establishing a data link between the vehicle and the remote monitoring 

recipient; 

- collecting vehicle operation data from data sources in the vehicle; 

10 - packaging the vehicle operation data in a data packet using protocol derived 

from SNMP; and 

- conveymg the data packet over the data link. 

15 2. A method of conveying vehicle operation data from a vehicle server to a remote 
monitoring client, comprising the steps of: 

- establishing a data link between the vehicle and the remote monitoring client; 
20 - coUectingvehicleoperationdatafromdatasourcesinthevehicleserver; 

- packaging the data in a protocol data unit having a protocol data xmit payload, 
. the payload including a plurality of VARIABLE BINDING fields, each 

VARIABLE BINDING field having an OBJECT IDENTIFIER field of two 
25 bytes, a VALUE TYPE field of one byte and a VARIABLE BINDING value 

of a size according to the VALUE TYPE field ; and 

- conveying the protocol data unit over the data link. 

30 3 Amethodofcollectingvehicleoperationdatafromavehicleforlaterfransmissiontoa 
remote monitoring recipient in a manner to minimize the bandwidth re^^^ 
the later transmission, comprising the steps of: 
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- providing a vehicle on-board computing device; 

- providing a number of data acquisition modules, each to measure one or more 
operating characteristics of the vehicle, the operating characteristics 
corresponding to current values of a set of managed objects; 

- interfacing the vehicle on-board computing device with each of the data 
acqmsition modules; 

- configuring the vehicle on-board computing device to: 

a) form a diagnostic information base for receiving and storing values for 
each of the managed objects firom each of the correspondmg data 
acquisition modules; 

b) assemble an event report based on information contained in the 
diagnostic information base; and 

c) package the event report in a protocol data unit acc9rding to an SNMP- 
derived protocol. 

4. A method as defined in claim 3 wherein the operating characteristics include GPS 
position, engine speed, road speed, or engine temperature, or an OBD-II parameter 
related to vehicle emissions. 

5. A method as defined in claim 4 wherein the OBD-H parameter includes misfire 
detection. 

6. A method as defined in claim 3, further comprising the step of enabling the vehicle on- 
board computing device to: 

a) estabUsh a data Unk with the remote monitoring recipient; and 
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b) convey the protocol data unit over the data link. 

7 A method as defined in claim 6, further comprising the step of enabling the remote 
monitoring recipient to issue a GET protocol data unit to retrieve the current values for 
a specific set of managed objects from the vehicle on-board computing device. 

8 A method as defmed in claim 7 further comprising the step of enabling the remote 
monitoring recipient to wait for an acknowledgement to the GET protocol data unit by 
the vehicle on-board computing device. 

9 A method as defined in claim 6, fi^er comprising the step enabUng the vehicle on- 
board computing device to issue a TRAP protocol data unit to report a vehicular event. 

10. A method as defined in clahn 9 fiirther comprising the step of enabling the vehicle on- 
board cornputing device to: 

a) store threshold values or a reporting interval for each vehicular event; and 

b) issue each TRAP protocol data unit, either when a threshold value has been 
exceeded or at a correspondmg reporting interval. 

11. A method as defined in claim 10 wherein the TRAP protocol data unit reports a GPS 



12. A method as defined in claim 6, fiorther comprising the step of issuing an INFORM 
protocol data unit fiom the vehicle to report an exceptional vehicular event. 

13. A method as defined in claim 12, firfier comprising the step of enabling the vehicle 
on-board computing device to: 

a) Store any one of a plurality of specified exceptional vehicular events in the 
diagnostic information base, including one or more regulatory exceptions, 
maintenance exceptions or operational exceptions; and 
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b) issue the INFORM protocol data unit when any one of the specified events 



occurs. 
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14. A method as defined iii claim 13 wherein the INFORM protocol data unit is sent as a 
result of a regulatory threshold level being exceeded. 

15 A method as defined in claim 13 further comprising the step of enabling the vehicular 
onboard computing device to wait for a confirmation that a previous INFORM 
protocol data unit has been logged in a data base by the remote monitoring recipient. 

16 A method as defined in claim 15, forther comprising the step of retransmitting the 
INFORM protocol data unit in the absence of a confirmation that a previous INFORM 

, protocol data unit has been logged in a database by the remote monitoring recipient. 

17 A method as defined in clahn 6, fiirther comprising the step of enabling the remote 
monitoring recipient to issue a SET protocol data unit to the vehicle on-boaxd 
computing device to set one or more of the managed objects. 

1 8 A method as defined in claim 6. wherein the data link is wireless and includes an 
radio frequency band under the IEEE 802.11 standard, a satellite RF packet network 
or a terrestrial RF packet networic. 

19 A method as defined in claim 6 wherein the protocol data unit is a REQUEST 
■protocol data unit, the protocol data unit excluding the ERROR STATUS and ERROR 

INDEX fields of the SNMP protocol. 

20. A method as defined in claim 6 wherein the protocol data unit excludes the LENGTH 
field of each variable binding of the SNMP protocol. 

21 . A method of conveying vehicle operation data firom a vehicle to a remote monitoring 
recipient, comprising the steps of: 
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- estabUshing a data link between the vehicle and the remote monitoring 
recipient; 

' - collecting vehicle operation data from data sources in the vehicle; 

- packaging the vehicle operation data in a data packet using protocol derived 
from SNMP; and 

- conveying the data packet over the data link, the protocol data unit being issued 
in response to a request by the remote monitoring recipient and containing both 
the request and requested values in the request and being encapsulated within a 
single message and in a single unfragmented network packet. 

A method of collecting vehicle operation data from a vehicle for later transmission to 
a remote monitoring recipient m a manner to minimize the bandwidtt requirements 
for tiie later transmission, comprising the steps of: 

- providing a vehicle on-board computing device; 

- providing a number of data acquisition modules, each to record a current value 
of a managed object of the vehicle; 

- interfacing the vehicle on-board computing device with each of the data 

acquisition modules; 

- configuring the veWcle on-boaid computing device to: 

a) form a diagnostic information base for receiving and storing values of 
the mam^ed objects from each of the data acquisition modules; 

b) assemble an event report based on information contained in the 
diagnostic information base; and 
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c) package the event report into a protocol data unit, the protocol data unit 
including a protocol data unit payload having a plurality of VARIABLE 
BINDING fields, each VAIOABLE BINDING field having an OBJECT 
IDENTIFIER field of two bytes, a VALUE TYPE field of one byte and a 
VARIABLE BINDING value of a size according to the VALUE TYPE 
field. 

23. A method as defined in claim 22 wherem the protocol data unit includes a header 
having a PDU TYPE data element with a value corresponding to one of a set of 
values, the set including a GET value, a SET value, a TRAP value, an INFORM value 
and a RESPONSE value. 

24. A computer implemented system for conveying vehicle operation data fix>m a vehicle 
to a remote monitoring recipient, comprising: 

- an vehicle on-board computing device in communication with a number of 
vehicle operation data sources in the vehicle; 

- a wireless communications device for establishing a wireless data link with the 
vehicle on-board computing device and the remote monitoring recipient; 

- the vehicle on-board computing device being enabled to package the vehicle 
operation data in a data packet using protocol derived firom SNMP for 
transmission to the remote monitoring recipient over the wireless data link. 

25. A computer-readable data structure for collecting and conveying vehicle operation 
data ftom a vehicle to a remote monitoring recipient, comprising: 

- an application module for receiving vehicle operation data ftom a number of 
data sources in the vehicle; 

- a storage module for storing a diagnostic information base, the diagnostic 

information base including a number of managed objects for a number of 
56 



SUBSTITUTE SHEET (RULE 26) 



vehicle operation parameters and a number of values for each of the managed 
objects; and 

. a communication module for conveying protocol data units under a protocol 
derived ftom SNMP over a wireless data link to the remote monitoring 
recipient. 

26 A computer program product encoded in a computer readable medium including a 
plurality of computer executable steps for a computer on-board a vehicle for 
collecting aad conveying vehicle operation data from the vehicle to a remote 
monitoring recipient, comprising: 

- receiving vehicle operation data from a number of data sources in the vehicle; 

- storing, in a diagnostic information base, a plurality managed objects for each 
of a number of vehicle opemtion parameters and a plurality of values for each 
of the managed objects; 

- estabUshing a wireless data link between the computer and the remote 
monitoring recipient. 

- conveying a number of protocol data units under a protocol derived from 
SNMP over a wireless data link to the remote monitoring recipient. 

27 A signal propagated on a carrier medium, the signal including a packaged protocol 
data unit containing a payload encoding predetemiined operational data of an 
automotive vehicle, according to a protocol derived from SNMP. 

28 A signal as defined in claim 27, the payload including a pluraUty of VARIABLE 
BINDING fields, each VARIABLE BINDING field having an OBJECT 
IDENTIFIER field of two bytes, a VALUE TYPE field of one byte and a VARIABLE 
BINDING value of a size according to the VALUE TYPE field data unit. 
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29. A signal as defined in claim 27 wherein the payload includes a GPS position segment, 
a GPS heading segment, a vehicle speed segment or an OBDH vehicle emissions 



30. A system for conveying vehicle operation data from a vehicle to a remote monitoring 

recipient, comprising: 

- vehicle on-board computing means in communication with a number of vehicle 

operation data source means in the vehicle; 

- wireless commumcations means for establishing a wireless data link with the 
vehicle on-board computing means and the remote monitoring recipient; 

. - the vehicle on-board computing means being enabled to package the vehicle 
operation data in a data packet using protocol derived from SNMP for 
transmission to Ihe remote monitoring recipient over the wireless data link. 

3i: A method of conveying vehicle operation data from a vehicle to a remote monitoring 
. recipient, comprising: 

. a step for establishing a data link between the vehicle and the remote 
monitoring recipient; 

. - astepforcoUectingvehicleoperationdatafromdatasourcesinthevehicle; 

- a step for packaging the vehicle operation data in a data packet using protocol 
derived from SNMP; and 

- a step for conveymg the data packet over the data link. 

32 A communications network for exchanging data between a plurality of vehicles, 
comprismg a computing unit onboard a corresponding vehicle, wherein the computing 
unit in a given vehicle is operable to broadcast identity messages and to receive 
equivalent identity messages from other vehicles in an adjacent region, where said 



SUBSTITUTE SHEET (RULE 26) 



e used to identify the neighbouring vehicles in the network for exchanging 
data with selected ones of the vehicles therein. 

33 A network as defined in claim 32 wherein the computing unit is operable to update a 
listofneighbourmgvehiclesandwhereintheinherenterror insaidGPS information is 
constant across all network nodes so that a neighborhood geography can be 
established in terms of relative, instead of absolute, positions. 

34 A network as defined in claim 33 wherein the computing untt adds new neighbour 
vehicles to the Ust as identity messages are received fix>m new vehicles entering the 
region. 

35 A network as defined in claim 34 wherein the computing unit deletes a given 
neighbour vehicle firom the list when identity messages are not received firom the 
given neighbour vehicle after a predetermined period of time. 

36 A network as defined in claim 35 wherein the computing unit deletes a given 
neighbour vehicle vehicles from the neighbour database when identity messages 
received from the given neighbour vehicle indicate that the neighbour vehicle is 
leaving or has left the adjacent region. 

37 A network as defined in claim 33 wherein the medium of coitamunications is a high 
frequency channelized RF band and its use by each of said computing umts xs 
controlled according to the ffiEE 802.11 Medimn Access Control (MAC) protocol. 

38. A network as defined in claim 33 wherein said computing units are 



39. A network as defined in claim 33 wherein said computing units are IPv6 addressable. 

40. A network as defined in claim 33 wherein said computing units exchange data usmg 
an SNMP-derived protocol. 
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41. A network as defined in claim 33 wherein the identity messages include GPS 
information and the ffiEE 802.1 1 MAC address of the sender. 

42. A network as defined in clahn 40 wherein the GPS information includes latitude, 
5 longitude, speed and heading infonnation. 

43. A network as defined in claim 42 wherein all vehicles in the neighbourhood broadcast 
their identity messages over a discovery time period that is sufficient to allow any 
given vehicle to recognize all its neighbours. 

.10 

44. A network as defined in claim 43 wherein channel selection for transmission of af 
least some messages is based on GPS heading. 

45. A network as defined in claim 44 wherein both the length of the discovery period and 
15 the geographic size of the region may be adjusted in proportion to the average speed 

of the vehicles in the neighbourhood. 

. 46. A network as defined in claim 43, wherein each of said computing units further 
comprise a transmitter and receiver capable of transmitting and receiving messages 
20 vmder an SNMP protocol. 

47. An automotive vehicle as defined in claim 32. 

48. A data structure comprising a speed segment, a heading segment and position 
25 segment. 

49. A data structure as defined in claim 48 wherein the position segment includes a 
longitude portion and a latitude portion. 

50. A signal propagated on a carrier medium, the signal, including a speed segment, a 
30 heading segment and a position segment. 

51. A signal as defined in claim 50 wherein the position segment includes a longitiide 
portion and a latitude portion. 
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52 A vehicle comprising ah onboard computing unit operable to receive messages from 
other vehicles in an adjacent region for assemblmg a neighbourhood list for 
exchanging data with selected ones of the vehicles Usted therein. 

53 A computer program product for operating a programmable computer system on 
board a motor vehicle, comprising a computer readable medium including the 
computer executable steps of receiving messages from other vehicles in an adjacent 
regionandofassemblinganeighbourhoodUstforexchangingdatawithselectedones 

of the vehicles listed therem. 

54 A motor vehicle comprising an onboard general purpose computer and a spread 
spectrum radio, the spread spectrum radio operable to estabUsb a data link v^th a 
radio in at least one other neighbouring vehicle, wherein the computer is operable to 
record messages from at least one other vehicle in an adjacent region for assembhng a 
neighbourhood list, and to identify at least one vehicular event from dala received on 
the data link. 

55 A computer-readable data structure for collecting and conveymg vehicle operation 
data from a vehicle on-board computing device and aremote monitoring recipient, 

comprising: 

- a module for indexing a services of protocol values and corresponding requests 
and responses for data exchange between the vehicle on-board computmg 
device and the remote monitoring recipient; 

. amodule for indexing a series of managed objects for a number of operating 
characteristics of the vehicle; 

3 - a module for recording values for each ofthe managed objects. 

56. A data structure as defined in. claim 55, further comprising a module for indexing 
an identity for each remote monitoring recipient. 
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57. A data structure as defined in claim 56, further comprising a module for indexing 
list of one or more managed object conditions for each remote monitoring recipient . 
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